< previous page page_166 next page >

Page 166
be valid. Object-oriented architects work with analysts and designers to ensure that project team members are able to trace the names of business objects between the list of requirements, analysis models, and design models. Architects sometimes perform the roles of both the analyst and designer; otherwise, the architect is a mediator and final decision-maker with regard to the system architecture. With the advent of the software reuse structure of the business organization, these roles will become more specialized (partitioned into smaller roles).
You then learned that the problem statement is used to capture, in plain English, how the user sees the system helping her complete her business processes. From this problem statement, the analyst and architect identify and list meaningful nouns and verbs, which helps the technicians identify potential actors, classes, class behavior, and use cases. After a list of these objects is drafted, the superfluous or vague items are discarded in favor of those with stronger meaning to the current problem domain (or business context). The main artifacts of the analysis process are the problem statement, the use case model, and an analysis class model.
On Day 3, Fundamental Object-Oriented Design, you learned the fundamentals of object-oriented design. This includes the creation of class diagrams that reflect the Visual Basic class modules you discovered you need, as well as interaction diagrams that show how these classes interact to carry out user requirements.
In the first three lessons, you learned about the concepts of object technology and received a primer on object-oriented programming. On Day 4, Fundamental Object-Oriented Programming, you took your learning a step farther. You learned how to construct actual Visual Basic code from the simple sequence diagrams you created in previous lessons. You received some background on generating code in Rational Rose and Visual Modeler, as well as identifying the known technical constraints of Visual Basic. After you generated some sample code, you got an idea of how to put the finishing touches on the application.
Day 5, Class Interface Inheritance in Visual Basic, covers class interface inheritance, in which one class implements the interface (public methods and properties) of another class. Specifically, you learned that a Visual Basic class is representative of a logical unit that is abstracted above mere code. A class interface is a contract with a client of that class that must be serviced. Building good interfaces is a fundamental part of reuse, but planning for any form of reuse is very difficult and initially will slow down a project. The distinction between interface and implementation classes is very important in component development. You learned that interfaces are what a component makes available to its clients.

 
< previous page page_166 next page >

If you like this book, buy it!